Restore the MCP tracer config, and trace the api → maple-ai hop - #868

Follow-up to #861. Four things the split changed by omission, plus the tests that would have caught two of them.

The MCP tracer config did not move with the surfaces

apps/api passed WorkerTelemetry two options that maple-ai did not:

• anticipatedErrorIdentifiers: MCP_ANTICIPATED_ERROR_IDENTIFIERS — what keeps an expected 400/401 (a tool call that does not decode, a missing or invalid credential) exporting with an Ok status and no exception event. resolve-tenant.ts documents the mechanism and then relied on a config that no longer set it, so every anticipated MCP rejection was landing in Maple's own error tracking as an unexpected error.
• dropSpanNames: ["McpServer/Notifications."] — which stayed behind on api, where nothing serves MCP any more.

The existing guard could not see this: it only inspects tracers built through MapleCloudflareSDK.make, and the request-facing one is built by WorkerTelemetry in the Worker init. It now covers that too, and I checked it fails when the line is removed.

maple-ai also gets the TracerDisabledWhen filter the bridge's tracer reads, so a liveness probe does not span. Header redaction stays at Effect's defaults, which already cover every credential reaching this Worker.

The forward carried no trace context

fromCloudflareFetcher calls the binding through a raw fetch and nothing instruments outbound calls, so maple-ai opened a new root trace and one /mcp call read as two unrelated traces with no edge between the Workers on the service map. The forward now replaces traceparent with api's own server span. Everything else still crosses byte for byte, streams included.

The forward had no test, and an inline cast

The path predicate is the contract between the two Workers — a path it misses 404s from api's router, one it over-matches never reaches api's routes at all — and both failures are invisible to a typecheck. It moves to worker/ai-forward.ts with a table in both directions, plus coverage of header, body and host preservation and the injected traceparent. The binding is narrowed by a guard rather than asserted into the fetcher type, so a present-but-wrong binding is a logged 503 instead of a defect inside alchemy's adapter.

The Workflow bound api's database consumer

MapleDb(consumer) picks the Hyperdrive config MAPLE_DB binds on the host script, and the fan-out Workflow still named "api" while its host yields "ai" — two MAPLE_DB binds on maple-ai, harmless only while both resolve to the same config. That is exactly the state the maple-ai-prd TODO exists to end.

Also moves @maple-dev/effect-sdk to dependencies, where chat/turn-runner.ts imports it from production code, and corrects two comments that still name apps/api as the Workflow's host.

Checks

@maple/ai typecheck, apps/api tsc, oxfmt and oxlint on every touched file, and the forward, graph-boundary and expected-failure suites. All green. The repo-wide typecheck and full suite are CI's.

Still not code

Two prd gates from the review remain open: the dedicated maple-ai-prd Hyperdrive config does not exist, so maple-ai serves prd traffic off api's pool, and the "Prod revision skew" alert rule (its SQL lives in the production database) has to list maple-ai.

🤖 Generated with Claude Code

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}